OpenKruise Agents v0.6.0 chega com controle de rede L4/L7, autoscaling de pools e pause/resume automáticos para Agent Sandboxes
O OpenKruise Agents é um subprojeto do OpenKruise, projeto open source da CNCF para automação de aplicações e orquestração de workloads. Ele oferece gerenciamento completo do ciclo de vida de Agent Sandboxes executados em escala no Kubernetes, com um runtime que cobre rede, armazenamento e identidade. Expõe interfaces Kubernetes e E2B, para que times de infraestrutura, de plataforma e engenheiros de algoritmos de IA operem os sandboxes com facilidade.
A v0.3.0 tratava de como atualizar, redimensionar e contabilizar um Sandbox depois de entregue a um Agent, e o roadmap prometia duas coisas: governança de rede via TrafficPolicy / SecurityProfile e uma integração de identidade de segurança que mantém credenciais da plataforma fora do código do Agent. A v0.6.0 entrega as duas e acrescenta a estrutura operacional em volta, com 283 pull requests integrados e 27 novos contribuidores desde a v0.3.0. O post detalha quatro capacidades: controle de acesso de rede L4 e L7 com gerenciamento de token (alcance de destinos, inspeção por requisição, ACLs no nível de ferramentas MCP e injeção de credenciais a partir de Kubernetes Secrets); SandboxUpdateOps com CheckpointRestore e upgrades de instâncias pausadas, que permitem atualizar em lote uma frota hibernada sem acordá-la manualmente e sem perder o filesystem; PoolAutoscaler, com capacidade declarativa de warm pool por watermarks e agendamentos cron; e pause/resume automáticos, com detecção de ociosidade por probes, wake agendado e wake-on-traffic, para que Sandboxes ociosos deixem de consumir CPU.
Segundo o texto, a versão passa de quatro para seis componentes, com traffic-control-plane e traffic-proxy. O egress deixa de ser responsabilidade do próprio Pod: é capturado dentro dele, roteado por um egress gateway e decidido por um motor de políticas que enxerga a requisição completa. O ingress gateway também pode acordar um sandbox, viabilizando o wake-on-traffic sem poller externo. Os CRDs dobram de 6 para 12, incluindo PoolAutoscaler, TrafficPolicy, GlobalTrafficPolicy, SecurityProfile e GlobalSecurityProfile, formando um sistema de controle em múltiplas camadas (cluster, tenant e sandbox).
O data plane captura o tráfego em dois estágios: L4 no lado do nó, com latência muito baixa, e L7 centralizado no gateway, para operação, observability e auditoria unificadas. Negações L4 são descartadas antes de chegar ao gateway, e o L7 nunca sobrepõe uma negação L4. Quando uma TrafficPolicy seleciona um Pod, o egress sem regra de permissão correspondente é negado, como em uma whitelist. Atenção: regras sem o campo peer são ignoradas pelo compilador e não formam um default deny, então um erro de digitação pode enfraquecer a política silenciosamente.
CEVIU DevOps··Leitura de 3 min